Printing engines such as laser printers, plotters, and other printing devices produce an image or “visual representation” on a sheet of paper or the like. A printing engine can print dots on a piece of paper corresponding to the information of a bitmap (or pixelmap where a pixelmap is characterized as having a depth of one, two or more bits) which forms an input for the printing engine. A bitmap (or bitmap file) forms a digital representation of the visual representation of the page to be printed. A printing device creates a visual representation by printing an array of pixels arranged in rows and columns from the bitmap.
Such a printing engine may be used to produce books, newspapers, pamphlets, posters and other single and multi-page printed matter. The printing press may advantageously print multiple pages of printed matter at the same time onto a single sheet. Besides printing presses other devices used for printing multiple pages at the same time include e.g. image setters and plate setters.
The data for each single page are conventionally in a page description language file (PDL). For that purpose each page may have been e.g. produced by a Page Layout applications such as e.g. Quark Express, PageMaker etc., the data having been put in a page description language file (PDL). A page description language (PDL) is a high level language for describing objects to be displayed by an output device. Examples of PDL are PDF and Postscript. These PDL files conventionally form the input for the system in accordance with the invention.
Conversion means that produce a bitmap output file in response to a number of page description language input files are widely used. Such a conversion means has a means (e.g. an interface) for receiving page description data in the form of a number of PDL files. In order to produce a finished sheet, the conversion means interprets the data contained in the PDL files, renders objects within the data into bitmap(s), and after all objects for the sheet are rendered, sends the bitmap file to a printing engine which prints the sheet.
Layout information describes how the pages are to be arranged to achieve the desired output result.
Rendering, i.e. PDL-to-bitmap transformation is another key processing-component of a printing process workflow system. The document processing system comprises a rendered to perform this task.
In a Job Ticket driven system a Job Ticket defines how a Job is to be assembled and processed. It defines the pages that are to be assembled and the processing settings for the pages and the flats, e.g. imposition, separation, trapping, rendering, etc. The job ticket is a detailed description on how a job is processed in the system. Job tickets are made via a Job Ticket editor and submitted to a server or are imported from another system e.g. print management system like an MIS or a Delano system. A number of specifications are used within the graphic arts industry such as e.g. the JDF specification and the PJTF specification for the job ticket for use as an interchange mechanism-between MIS systems and server.
To the different steps of the printing process parameters are associated, such as for instance parameters relating to resolution, color management, imposition schedule, trapping, rendering etc. The JDF specification and the PJTF specification enumerate many of the known processes and their associated parameters. The control system comprises an input source with a user interface for enabling a user to define or change processing parameters, often a graphical user input (GUI).
The user may define or change parameters explicitly and knowingly, for instance when resolution or is increased or color settings are changed, in which case it may be clear to the user which parameters he is changing, or implicitly for instance when the press is changed, which may effect several printing process parameters such as e.g. those associated with color management and trapping.
Also the user may change parameters relating not to a task or action within the workflow (resolution, imposition, color setting parameters etc.), but to the workflow itself e.g. by changing the sequential order of tasks to be performed in the workflow scheme (e.g. changing from a workflow scheme in which rendering is done prior to imposition to a workflow scheme in which imposition is done prior to rendering), i.e. change parameters for the workflow.
Under normal conditions one can assume that job tickets or jobs are submitted and run to completion with the preset values. This assumes that during the course of execution of the job nothing changes in the specification of the job or by implication nothing changes in the job ticket.
However sometimes mistakes are made or choices made by the client or operator are less then perfect or very simply a change of mind occurs. Such mistakes or less than perfect choices or changes of mind can be for instance:                the wrong interpretation of the customer specification of the job into job specific settings in the job ticket        content errors or modifications like typo's, price changes, late updates, breaking news, etc.        Changing customer requirements: other screen, other resolution, other color settings        Changing printing requirements; modified trapping, other web compensations . . .        Changing planning, e.g. intended equipment to produce the job is not available and a different equipment have different parameters must be used . . .        etc.        
Mistakes or changing requirements require known job control systems to abort the job in process. At that moment in time the operator has a few choices.
For simplicity reasons the operator might decide that the job parameters are changed in the job ticket and a completely new job is submitted, yielding the new output requirements. This puts a high burden on the prepress processing system. All intermediate results need to be regenerated. The consistency of the output is guaranteed. As mistakes are often detected in the proofing cycle late in the production, the response time to changes is vital to maintain press-up times (cost, customer satisfaction),
The operator might also, at least theoretically, decide to intervene into the prepress system and try to split up the job in a part that can be re-used for further processing and another part that needs to be resubmitted from scratch with the new settings in the job ticket. This is a time consuming and difficult process and prone to errors, especially given the fact that there is usually little response time available and the choices have to be made under great time pressure.
Neither of the choices is, especially late in proofing cycle late in production, an attractive choice. However, present job control systems do not provide any other solution.